package run.halo.app.model.vo;

import java.util.Comparator;
import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.ToString;

/**
 * Month archive vo.
 * @author johnniang
 * @date 4/2/19
 */
/*
TODO LYF

https://www.cnblogs.com/bichon/archive/2012/06/28/2567027.html
vo的作用有两种：
1.模块隔离：对外暴露，屏蔽内部实现。
2.分布式支持：用于异步传输；

换句话说：
如果不打算进行严格的模块化/组件化，又没有分布式场景，就不应该使用VO。
如果不打算进行严格的模块化/组件化，但存在部分分布式场景，比如lz所说的flex，那么针对部分进行VO开发即可；

https://blog.csdn.net/qq_41829904/article/details/90465586
一、PO:persistant object 持久对象
可以看成是与数据库中的表相映射的java对象。使用Hibernate来生成PO是不错的选择。

二、VO:value object值对象。
通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象
可以和表对应,也可以不,这根据业务的需要.

有一种观点就是：PO只能用在数据层，VO用在商业逻辑层和表示层。各层操作属于该层自己的数据对象
这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。
如果将PO用在各个层中就相当于我们使用全局变量，我们知道在OO设计非常不赞成使用全局变量。
但是每次都得进行VO-PO的转换，也确实很烦。我觉得有时候也可以在某个商业逻辑或者表示层使用PO
此时在这个商业逻辑的过程中PO的状态是不发生变化的，比如显示一条商品详细信息的商业逻辑。
在开发过的项目中，规模都很小，我一直都把PO当VO用，因为PO确实很方便，结合Hibernate的DAO
我使用JAVA的集合对象作为值传递的载体，当然Struts也是我的不二之选。
我认为：在一些直观的，简单的，不易发生变化的，不需要涉及多个PO时，传递值还是使用PO好
这样可以减少大量的工作量（也就意味着减少bug，减少风险），也不需要担心未来的维护工作!

vo:value object,值对象
一般在java中用的多的是pojo:plain oriented java object
原始java对象，pojo一般和数据库中的表是一一对应的。
vo一般是来做值的存储与传递。
https://www.cnblogs.com/chancy/p/9758804.html
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class ArchiveMonthVO extends ArchiveYearVO {

    private Integer month;

    public static class ArchiveComparator implements Comparator<ArchiveMonthVO> {

        @Override
        public int compare(ArchiveMonthVO left, ArchiveMonthVO right) {
            int compare = right.getYear() - left.getYear();

            if (compare != 0) {
                return compare;
            }

            return right.getMonth() - left.getMonth();
        }
    }
}
